home *** CD-ROM | disk | FTP | other *** search
/ NetNews Offline 2 / NetNews Offline Volume 2.iso / news / comp / lang / c++-part1 / 3580 < prev    next >
Encoding:
Internet Message Format  |  1996-08-06  |  3.9 KB
  1. Path: redstone.interpath.net!usenet
  2. From: fortunat@interpath.com (Jumpstile Turner)
  3. Newsgroups: comp.graphics.algorithms,comp.lang.c++,comp.os.ms-windows.programmer.graphics,comp.os.ms-windows.programmer.multimedia,comp.os.ms-windows.programmer.win32
  4. Subject: Re: IJG JPEG Engine and Win32
  5. Date: 21 Jan 1996 10:21:11 GMT
  6. Organization: Completely unorganized
  7. Message-ID: <4dt42n$pu3@redstone.interpath.net>
  8. References: <4cemir$6vb@redstone.interpath.net> <TGL.96Jan3202549@netcom21.netcom.com> <TGL.96Jan5065424@netcom21.netcom.com> <4cpn1r$gm0@redstone.interpath.net> <4crai5$ear@hades.rz.uni-sb.de> <4d11tg$56q@redstone.interpath.net> <310110c0.44581633@news.connectnet.com>
  9. NNTP-Posting-Host: fortunat.pdial.interpath.net
  10. X-Newsreader: WinVN 0.99.7
  11.  
  12. In article <310110c0.44581633@news.connectnet.com>, 
  13. jtara@connectnet.com said:
  14. >I'm not sure that using VirtualAlloc() would be such a good idea,
  15. >except for large blocks. malloc() and free() grab large blocks and
  16. >then divvy them up, so most of the time when you call malloc() it
  17. >doesn't actually go out to the operating system and allocate anything.
  18.  
  19.  
  20.   Well, I myself use HeapAlloc for the mempry calls.  HeapAlloc is 
  21. smart in that it will use VirtualAlloc if necessary completely 
  22. transparently.
  23.  
  24. >Are you sure that GlobalAlloc doesn't wind up calling
  25. >
  26.  
  27.   You didnt finish this line.  I assume you mean GlobalAlloc doesn't 
  28. wind up calling HeapAlloc?  As far as I understand GlobalAlloc still 
  29. calls 16-bit memory rather than 32-bit memory.  I could be wrong, but 
  30. in one of my Win32 books floating around here it states that Win95 
  31. Explorer still uses GlobalAlloc to allocate memory for "Drag and Drop" 
  32. data structures and that this is 16-bit RAM it is allocating.  It also 
  33. states that GlobalAlloc is much slower than using HeapAlloc or 
  34. VirtualAlloc.  I haven't tested this much, but it sure SEEMS slower 
  35. when I switch HeapAlloc calls to GlobalAlloc.  Although this might be 
  36. the power of suggestion. :)  However I've read this in more than one 
  37. place so I'd just assume it was correct.
  38.  
  39. >The IJG library can make use of the ability to "back up" in the file -
  40. >that way, it can avoid allocating some buffers in some cases. Not sure
  41. >if this really gains you much.
  42. >
  43. >Rather than sucking the files into RAM, though, why not just
  44. >memory-map the file?
  45.  
  46.    Well, if reading it into RAM from the start isn't any faster than I 
  47. don't think I'll get any speed benefit by converting it to a memory 
  48. mapped file.  After all, its basically just converting file accesses to 
  49. memory accesses.  I would think I'd end up with a little more overhead 
  50. this way, although memory mapped files are certainly usesful.
  51.  
  52. >In my app, I bring the JPG in and out through a CArchive, which
  53. >precludes direct access to the file (I could be serializing from/to a
  54. >CSocket, for example) and backing up. This would be a case for sucking
  55. >it into memory first, IF there is a significant advantage to being
  56. >able to back up.
  57. >
  58. >Right now, though, I'm perfectly happy with malloc() for allocation
  59. >and letting the default MFC code (in CDocument) read the file for me.
  60. >It seems significantly faster than Lview Pro (not sure why - I have
  61. >the 32 bit version - is it not using the IJG code?) so I'm happy.
  62.  
  63.  
  64.   Whatever works is good enough I guess. :)  I find that my compilation 
  65. is at least as fast as LView and noticeably faster for larger JPEG 
  66. images.  Of course changing the DCT options makes a large difference.  
  67. Incidently I don't notice any difference in image quality if I use 
  68. floating point or slow integer DCT as opposed to fast integer.  Other 
  69. than the significantly longer decompression times, there is barely any 
  70. difference at all (that I can see) if there is one.  Is it the same on 
  71. your end?  Perhaps my eyes are failing me. :)
  72.  
  73.  
  74.            -Scott
  75.  
  76. ------------------------------------------------
  77. Jumpstile Turner
  78. fortunat@interpath.com
  79. "Sing the Hare Hare, Dance the Hoochie Koo..."
  80. ------------------------------------------------
  81.  
  82.